Skip to content

Conversation

@max-schaefer
Copy link
Contributor

The database type @xmlparent is defined a bit too loosely in that it includes all of @file, not just XML files. This meant that non-XML files were instances of XMLParent but not of any of its subtypes, thereby inheriting the default none()-implementation of getName(), causing their toString() predicates to be empty.

Fixing the extent of @xmlparent would involve fiddling with the extractor/dbscheme, while fixing XMLParent can be done at the QL level, so that's what I've done instead.

Fixes #2517.

@max-schaefer max-schaefer added JS WIP This is a work-in-progress, do not merge yet! labels Dec 12, 2019
@max-schaefer max-schaefer requested a review from a team as a code owner December 12, 2019 12:26
@max-schaefer
Copy link
Contributor Author

I'm going to do a very quick dist-compare to ensure this doesn't cause optimiser wobbles.

esbena
esbena previously approved these changes Dec 12, 2019
Copy link
Contributor

@esbena esbena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, with one comment to help our future selves.

* both of which can contain other elements.
*/
class XMLParent extends @xmlparent {
XMLParent() { this instanceof @xmlelement or xmlEncoding(this, _) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a comment here or in the extractor about why we do it like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, probably a good idea. Done.

The database type `@xmlparent` is defined a bit too loosely in that it includes all of `@file`, not just XML files. Fixing that would involve fiddling with the extractor/dbscheme, so I have opted to fix it at the QL level instead.
@max-schaefer max-schaefer removed the WIP This is a work-in-progress, do not merge yet! label Dec 12, 2019
@max-schaefer
Copy link
Contributor Author

A smoke-test evaluation (internal link) showed no changes.

I tried out DPM for this run, which worked like a charm (:tada:) and shows no changes to either tuple counts or predicted timings. I take that as evidence that join orders didn't change at all, so unless there is significant appetite for a more thorough evaluation I think this is good to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JS tests that are sensitive to default toString() methods

3 participants